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REMARKS 

Rejections Based on Lazaridis 

Claims 1-3, 5, 6, 11-13, 18-22, 24-32, 34-38, 40-47, 49-55, 57. 58, 6). and 63 were 
rejected under 35 U.S.C. Section 102(e) as being anticipated by U.S. Patent No. 6,463,464 to 
Lazaridis et aj. ("Lazaridis"). Claims 4, 7-10, and 14-17 were rejected under 35 U.S.C. 
Section 103(a) as being unpatentable over Lazaridis in view of U.S. Patent No. 6,442,571 to 
Haff ("Haff •). Claims 23, 33, 39, 48, 56, 59, 60, and 62 were rejected under 35 U.S.C. 
Section 103(a) as being unpatentable over Lazaridis in view of U.S. Patent No. 6,260,027 to 
Takahashi ("Takahashi"). 

The Lazaridis reference discloses an e-mail forwarding system wherein computers 
send e-mails to host device 10, which then forwards the e-mails to a mobile computer 24. 
The computer uses the network address of the host device 10 xo compose the e-mail and 
sends the e-mail directly to host device 10. After the host device 1 0 receives the e-mail sent 
to it, it determines whether to redirect the e-mail to the user's mobile computer 24 using 
re-director program J 2. See col. 7, lines 64-67; col. 8, lines 48-49. In this manner, the 
Lazaridis host device 10 is only able to forward messages to mobile computer 24. 

Claim 1 

With regard to claim 1, the Office Action states that the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. 

The Lazaridis reference does not leach "registering the user terminal by sending 
information regarding the user terminal from the transfer device to the information provider 
server". The Office Action cites col. 7, line 38 - col. 8, line 5, and col. 7, line 49 as support 
in the Lazaridis reference for teaching the "registering" limitation. A portion of the cited 
support is as follows: 

FIG. 1 shows an E-mail message A being communicated over LAN 14 from 
computer 26 to the user's desktop system 10 (also shown in FIG. 1 is an 
external message C, which could be an E-mail message from an Internet user 
or could be a command message from the user's mobile device 24). Once the ' 
message A (or C) reaches the primary message store of the host system 1 0 it 
con be detected and acted upon by the redirection software 12. The redirection 
software 12 can use many methods of detecting new messages. The preferred 
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method of detecting new messages is using MicrosolVsO'*) Messaging API 
(MAPI), in which programs, such as the redirecior program 12. register for 
notifications or advise syncs' when changes to ;i mailbox take place. Other 
, methods of detecting new messages could also be used with the present 
invention. 

* * * 

Also programmed into the redirecior J 2 is the address of the user's mobile data 
communication device 24, the type of device, and whether the device 24 can 
accept certain types of attachments, such as word processing or voice 
attachments. 

Col. 7. lines 38 - col. 8, line 5. Applicants respectfully disagree that this excerpt or any 
portion within the Lazaridis reference teaches the "registering" limitation. The Office action 
cites of particular relevance col. 7, line 49. However, this citation, apart from the word 
"register, 5 ' has no bearing on the limitation. The citation discloses that the redirector 
program 12 may "register" with Microsoft's® Messaging API (MAPI) in order to when to 
activate the redirector program. The redirector program forwards e-mail sent to the mailbox. 
When new mail is received, the MAPI sends a notification to the redirector program J 2, 
which may then review the new e-mail to determine what to do with it. The excerpt does not 
teach several aspects of the limitation. First, a "user terminal" is noi being registered. As 
clearly shown, only the redirector program, resident on desktop computer 10 is registered. 
Second, the excerpt does not teach that the user terminal is registered with the information 
provider server. Instead, the redirector program is registered with an application program 
interface (API) on desktop computer 10 and not with an information provider server. 

Other portions of the cited passage teach that the address of the user's mobile 
computer is programmed into the redirector program 12, Again, this excerpt does not teach 
the limitation that the user terminal is registered with the information provider server. 
Specifically, the user's mobile computer in the Lazaridis reference is only programmed into 
the redirection software. There is no teaching or suggestion that computer 26 or the like 
registers the address of mobile computer 24. In fact, the context of La2aridjs teaches away 
from registering the user terminal with computer 26 or the like. If mobile computer 24 were 
registered with computer 26. computer 26 would have no need for redirecior program 12, the 
focus of the Lazaridis reference, and could communicate directly with mobile computer 24. 

In the section entitled Arguments against Rejections of Claimed Features, the Office 
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Action stales that the Lazaridis disclosure leaches the "registering 7 ' limitation since 
"Lazaridis* disclosure includes mobile communications devices, including certain 
, attachments, such as word processing or voice (C;ol. 7, lines 64-67)." While applicants do 
not dispute that the Lazaridis does disclose mobile communication devices, including certain 
attachments, such as word processing or voice, applicants do not recognize how this teaching 
meets the "registering" limitation. Therefore, applicants believe that claim 1 as currently 
written, and claims dependent on claim 1 . are patentable over the cited art. 

Claim 3 

With regard to claim 3, the Office Action states that the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. 

First, the Lazaridis reference does not teach "modifying the identification information 

relating to the user terminals". The Office Action cites col. 3, lines 39-4 1 as support in the 

Lazaridis reference for teaching the "modifying 7 ' limitation. The cited support is as follows; 

[I]t is within the scope of this invention that such configuration may be set or 
modified through data sent from the mobile communications device. 

Apart from the term lt modified 5 " the above-excerpt teaches nothing about the "modifying" 

limitation. Rather, the "modifying" limitation is different from the above-execrpt, and the 

entire Lazaridis reference, in that the identification information, such as the address of 

mobile computer 24 : is not modified by redirection software 12 or the desktop computer 10. 

As discussed above, the Lazaridis is an intelligent mail-forwarder. Desktop computer 10 

receives an e-mail, and using redirection software 12, forwards the e-mail to mobile 

computer 24. In order to forward the e-mail, redirection software accesses the address of 

mobile computer 24 ? repackages the e-mail and sends it to mobile computer 24. Thus, 

Lazaridis teaches storing the address of mobile computer 24 but does not modify the address 

or other identification information of mobile computer . See coJ. 7, line 64 - col. 8, line 1 , 

"Also programmed into the redirector 12 is the address of the user's mobile data 

communication device 24, the type of device, and whether the device 24 can accept certain 

types of attachments, such as word processing or voice attachments." 

Second, the Lazaridis reference does not teach "sending the modified identification 

information to the information provider server". The Office Action cites col. 9, lines 41-47 
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as support in the Lazaridis reference for teaching ihe "sending 11 limitation. The died support 
is as follows: 

,'Jn this alternative configuration, server 1 1 preferably jnaimains a user profile for each 
user's desktop system 1 0 : 26, 28. including information such as whether a particular 
user can have data items redirected, which types of message and information to 
redirect, what events will trigger redirection, the address of the users' mobile data 
communication device 24. the type of mobile device, and ihc user's preferred list, if 
any. 

The above-referenced excerpt docs not teach two aspects of the limitation at issue. First, 
there is no teaching of modifying the identification information. Rather, the Lazaridis 
reference only teaches storing the address of the mobile data communication device. See 
above. Further, this modified information is not sent to any information provider, as required 
in the present limitation. Specifically, the Lazaridis reference does not teach thai the address 
(or a modified address) of mobile computer 24 is sent to computers 26, 28. 

Third, the Lazaridis reference does not teach "calling a relevant user terminal based 
on the stored identification information relating to user terminals, the modified identification 
information, and the user terminal identifier". The Office Action cites col. 4, lines 5-9 as 
support in the Lazaridis reference for teaching the "calling" limitation. The cited support is 
as follows; 

Once an event has triggered redirection of the user data items, the host system then 
repackages these items in a manner that is transparent to the mobile data 
communication device, so that information on the mobile device appears similar to 
information on the user's host system. 

The above-referenced excerpt does not teach the limitation at issue, Upon deciding to 

forward an e-mail, the Lazaridis reference merely accesses the stored address of mobile 

computer 24. It does not call the user terminal based on the modified identification 

information or the user terminal identifier, neither of which is sent to desktop computer )0. 

Therefore, claim 3, and claims dependent on claim 3, are patentable over the cited art. 

Claim S 

With regard to claim 5, the Office Action states that the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. 

First, the Lazaridis reference does not leach "storing user attribute data of users'*. The 
Office Action cites col. 3, lines 42-45 and col. 9, lines 41-58 as support in the Lazaridis 
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reference for teaching the "storing" limitation. The cited support is as follows: 

In addition to the functionality noted above, the rcdircctor program provides a set of 
software-implemented control functions for determining the type of mobile data 
communication device and its address, for programming a preferred list of message 
types that are lo be redirected, and for determining whether the mobile device can 
receive and process certain types of message attachments, such as word processor or 
voice attachments. 

In this alternative configuration, server J 1 preferably maintains a user profile for each 
user's desktop system 10, 26, 28, including information such as whether a particular 
user can have data items redirected, which types of message and information lo 
redirect, what events will trigger redirection, the address of ihe users' mobile data 
communication device 24, the type of mobile device, and the user's preferred list, if 
any. The event triggers are preferably detected at the user's desktop system 10, 26, 28 
and can be any of the external, internal or network events listed above. The desktop 
systems 10, 26, 28 preferably detect these events and then transmit a message to the 
server computer 1 1 via LAN 14 to initiate redirection. Although the user data items 
are preferably stored at the server computer 1 1 in this embodiment, they could, 
alternatively, be stored at each user's desktop system 10, 26, 28, which would then 
transmit them to the server computer 1 1 after an event has triggered redirection. 

The above-excerpts fail to teach storing "user attribute data of users." Both excerpts merely 

teach that the redirector program stores certain capabilities of the mobile device. For 

example, in the excerpt, Lazaridis merely leaches "whether the mobile device can receive 

and process certain types of message attachments", col. 3, lines 47-48. However, there is no 

teaching or even suggestion that user attributes, such as age, gender, etc., arc stored. 

Second, the Lazaridis reference does not teach "receiving . . . from said information 

provider server together with attribute information of users designated as desired 

destinations''. The Office Action cites col. 3, line 9 and col. 9, lines 48-58 as support in the 

Lazaridis reference for teaching the "receiving" limitation. The cited support is as follows: 

Also operating at the host system are various sub-systems that can be configured to 
create triggering events, such as a screen saver sub-system or a keyboard sub-system, 
as well as sub-systems for repackaging the user's data items for transparent delivery to 
the mobile data device, such as a TCP/IP sub-system or one or more E-Mail sub- 
systems. Other sub-systems for creating triggering events and repackaging the user's 
data items could also be present at the host system. The host system also includes a 
primary memory store where the user's data items are normally stored. (Col 3 lines 
3-12) 

The event triggers are preferably detected at the user's desktop system 1 0, 26, 28 and 
can be any of the external, internal or network events listed above. The desktop 
systems 10, 26, 28 preferably detect these events and then transmit a message to the 
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server computer 1 1 via LAN J 4 to initiate redirection. Although the user data items 
are preferably stored at the server computer 1 1 in this embodiment, they could, 
aliernatively, be stored at each user's desktop system 10. 26, 28 ; which would then 
transmit them to the server computer ] 1 after an event has triggered redirection. 
The above-excerpi fails to teach receiving "attribute information of users." The excerpt 
merely teaches that "user data items" may be stored. The Lazaridis reference teaches that 
"user data items" are specific types of data, such as e-mail 7 that may forwarded to mobile 
computer 24 based on pre-defined "triggering events; 1 ay taught in the following excerpt: 

A redirector program operating at the host system enables the user to redirect or 
mirror certain user-selected data items (or pans of data items) from the host system to 
the user's mobile data communication device upon detecting that one or more user- 
defined triggering events has occurred. 

Col. 2, line 66 - coJ. 3, line 3. At best, the excerpts merely teach that certain types of data 

items may be forwarded to the user. However, the excerpts fail to teach or even suggest that 

the information provider sends any attribute information of users, such as gender, age, etc. in 

order to identify potential users to send information to. 

Third, the Lazaridis reference does not teach "comparing said stored user attribute 

data and the designated user attribute data, and specifying network addresses of user 

terminals corresponding to users having the designated attributes". The Office Action cites 

col. 3, line 42 - col. 4, line 4 as support in the Lazaridis reference for teaches "modifying" 

limitation. The cited support is as follows: 

In addition to the functionality noted above, the redirector program provides a sei of 
software-implemented control junctions for determining the type of mobile data 
communication device and its address, for programming a preferred list of message 
types that are to be redirected, and for determining whether the mobile device can 
receive and process certain types of message attachments, such as word processor or 
voice attachments. The determination of whether a particular mobile device can 
receive and process attachments is initially configured by the user of that mobile 
device at the host system. This configuration can be altered on a global or per 
message basis by transmitting a command message from the mobile device to the host 
system. If the redirector is configured so that the mobile data device cannot receive 
and process word processor or voice attachments, then the redirector routes these 
attachments to an external machine that is compatible with the particular attachment, 
such as an attached printer or networked fax machine or telephone. Other types of 
attachments could be redirected to other types of external machines in a similar 
fashion, depending upon the capabilities of the mobile device. For example, if a user 
is traveling and receives a message with an attachment that the user's mobile device 
can process or display, the user may from a mobile communications device send a 
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command message 10 the host system indicating lhat lhat attachment is 10 be sent to a 
fax machine at a hotel where ibe user will be spending (he evening. This enables the 
user to receive important K-mail attachments as long as the host system is provided 
with sufficient information about, the destination where the attachment is to be 
forwarded. 

The excerpt teaches that the user may have a mobile device or other externa] devices. When 
an e-majj is sent to the redirector program, the rediredor program decides whether to 
forward the c-mail to the mobile device of the user or other external devices of the user 
depending on the type of e-mail. For example, if the mobile computer cannot handle voice 
or word processing and the e-mail is voice, the redirector program may send the e-mail to 
another external device of the user The above-excerpt fails to teach several aspects of the 
limitation at issue. First, the excerpt does not teach thai comparison of stored user attribute 
data with designated user attribute data. At best, Lazaridis teaches that the type of e-mail 
(voice, text, etc.), not the type of user (gender, age, etc.), is compared with capabilities of 
the mobile computer to determine whether the mobile computer can process the e-mai). 
Second, the excerpt does not teach specifying network addresses of user terminals having the 
designated attributes. Specifically, Lazaridis docs not teach that there is a list of potential 
recipients of the c-mail, and that based on user attributes defined sent from an information 
provider, one or more of the potential recipients is selected from the list. Instead, Lazaridis 
teaches that the recipient is already determined. The only thing to determine is which device 
associated with the recipient can process the e-mail (i.e., select one device from a list of user 
devices which can process an e-mail). Therefore, claim 5, and claims dependent on claim 5, 
are patentable over the cited art. 

Claim 11 

With regard to claim 1 1 , the Office Action states that the Lazaridis reference leaches 
each of the limitations. Applicants respectfully disagree. 

The Office Action recites the same basis for rejection as discussed above for claim 1 . 
For similar reasons as discussed above for claim 1, claim 1 1 is patentable over the cited art. 

Claim 12 

With regard to claim 12, the Office Action states that the Lazaridis reference teaches 
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each of the limitations. Applicants respectfully disagree. Similar to the arguments discussed 
above with respect to claim 3. the La/.aridis reference does not teach the "modification 
, means," "sending means/' and "calling means" limitations recited in claim 1 2. Therefore, 
claim ]2, and claims depending on claim )2 ; are patentable over the cited references. 

Claim 13 

With regard to claim 13, the Office Action states that the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. Similar to the arguments discussed 
above with respect to claim 5, the Lazaridis reference does not teach the "memory for 
recording user attribute information," "receiving means for receiving from said information 
provider server information supplied together with attribute information of users designated 
as desired destinations/ 7 and "specifying means for comparing the recorded user attribute 
information with the designated user attribute information, and specifying network addresses 
of user terminals which correspond to users having the designated attributes" limitations 
recited in claim 13. Therefore, claim 13, and claims depending on claim 13, are patentable 
over the cited references. 

Claim 24 

With regard to claim 24 ? the Office Action states that the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. 

The Lazaridis reference does not teach "rejecting the push-type information if the 

information provider is not registered with the transfer device. 1 ' The Office Action cites col. 

8, lines 6-37 as support in the Lazaridis reference for the "rejecting" limitation. The cited 

support is as follows: 

The redirector may also be programmed with a preferred list mode that is 
configured by the user either at the host system 10, or remotely from the user's mobile 
data communication device by transmitting a command message C. The preferred list 
contains a list of senders (other users) whose messages are to be redirected or a list of 
message characteristics that determine whether a message is to be redirected. If 
activated, the preferred list mode causes the redirector program 12 to operate like a 
filter, only redirecting certain user data items based on whether the data item was sent 
from a sender on the preferred list or has certain message characteristics thai if 
present will trigger or suppress redirection of the message. In the example of FIG 1, if 
desktop system 26 was operated by a user on the preferred list of host system 10, and 
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the preferred list opiion was activated, then message A would be redirected. If, 
however, desktop 26 was operated by a user not on the host system's preferred 
list, then message A would not be redirected, even if the user of the hOvSt system 
ha^d configured the redirector to push messages of type A. The user of ihe host 
system 10 can configure the preferred list directly from the desktop sysiem or. 
alternatively, the user can then send a command message (such as C) from the mobile 
device 24 to the desktop system 10 to activate the preferred list mode, or to add or 
delete certain senders or message characteristics from the preferred list that was 
previously configured. ]t should be appreciated that a redirection program could 
combine message characteristics and preferred sender lists to result in a more flnely- 
tuncd filter. Messages marked as low priority or that are simple return receipts or 
message read receipts, for example, could always be suppressed from redirection 
while messages from a particular sender would always be redirected. 

(emphasis added). The Lazaridis reference leaches that the user may configure a "preferred 

list." If an e-mail is sent from a party who is not on the preferred list, the e-mail is stored on 

the host system 10 (which the Examiner interprets as the claimed "transfer device") and not 

forwarded to mobile device 24. This is in contrast to the limitation at issue which claims the 

"transfer device" "rejecting the push-type information if the information provider is not 

registered with the transfer device. 7 ' In order to limited unwanted pushed information, the 

transfer device determines whether the sender of the pushed information is registered. If not, 

the transfer device rejects the pushed information. One type of rejection is "disposing of the 

push-type information. 5 ' See claim 25- Thus, Lazaridis does not "reject" the information as 

claimed. Instead, the host system in Lazaridis stores the e-maij and does not forward the e- 

mail to mobile device 24. 

Claim 36 

With regard to claim 36, the Office Action states that the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. 

The Lazaridis reference does not teach Registering the user terminals with the 

information provider servers by sending information regarding the user terminals from the 

transfer device to the information provider servers". The Office Action cites col. 7, line 38 - 

52 as support in the Lazaridis reference for teaches registering the user terminals with the 

transfer device and the information provider server. The cited support is as follows: 

FIG. 1 shows an E-mail message A being communicated over LAN )4 from computer 
26 to the user's desktop system 10 (also shown in FIG ) is an external message C, 
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which could be an E-mail message from an Internet user, or could he <i command 
message from the user's mobile device 24). Once Lhc message A (or C) reaches the 
primary message store of the host system 10, it can be detected and acicd upon by the 
redirection software 12. 'ITie redirection software 12 can use many methods of 
detecting new messages. The preferred method of detecting new messages is using 
Microsoft's® Messaging API (MAPI), in which programs, such as Ihe redirector 
program 12, register for notifications or * advise syncs' when changes to a mailbox 
take place. Other methods of detecting new messages could also be used with the 
present invention. 

As discussed above, neither this excerpt nor any portion within the Lazaridis reference 
teaches the "registering 57 limitation. Therefore, claim 36, and claims depending on claim 36, 
are patentable over the cited references. 

Claim 42 

With regard to claim 42, the Office Action states that the La?.aridis reference teaches 
each of the limitations. Applicants respectfully disagree. 

First, the Lazaridis reference does not teach "receiving, from the information provider 

server, ... a user terminal identifier for identifying the at least one of the user terminals, 

wherein the user terminal identifier is other than a network address of a user terminal". The 

Office Action cites col. 10, Jines 9-14 as support in the Lazaridis reference for the 

"receiving" limitation. The cited support is as follows: 

If the message C is from an Internet computer to the user's desktop system 1 0, and the 
user has redirection capabilities, then the server 1 1 detects the message C, repackages 
il using electronic envelope B, and redirects the repackaged message (C in B) to the 
user's mobile device 24. 

The cited passage does not meet the limitation. The message C in the cited passage does not 

include any address for u a user terminal identifier." The Internet computer which sends the 

message C addresses the message to the user's desktop system 10 (which the Office Action 

interprets as the transfer device). The message C does not include the address of any user 

terminal. For example, message C does not include the address of the mobile computer 24 

(which the Office Action interprets a? the user terminal). That address is added when the 

message C is repackaged using electric envelope B. In fact, if the address of the mobile 

computer 24 were included in message C, message C could be sent directly to mobile 

computer 24 (obviating the need for the user's desktop system 10). Thus, at best, message C 
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includes the address of the transfer device but not of the user terminal. 

Second, the Lazaridis reference does not tench "determining at least one user terminal 

to send the information to transmit based on the user terminal identifier and the user terminal 

information". The Office Action cites col. )2, lines 1-16 as support in the Lazaridis 

reference for the "determining" limitaiion. The cited support is as follows: 

FIGS. 4 and 5, set forth, respectively, flow charts showing the steps carried out by the 
rcdireclor software 12 operating at the host system 1 0, and the steps carried out by the 
mobile data communication device 24 in order to interface with the host system. 
Turning first to FIG. 4, at step 50, the redirector program 12 is started and initially 
configured. The initial configuration of the redirector 12 includes: (1) defining the 
event triggers that the user has determined will trigger redirection; (2) selecting the 
user data items for redirection; (3) selecting the repackaging sub-system, either 
standard E-Mail, or special -purpose technique; (4) selecting the type of data 
communication device, indicating whether and what type of attachments the device is 
capable of receiving and processing, and inputting the address of the mobile device; 
and (5) configuring the preferred list of user selected senders whose messages are to 
be redirected. 

The cited passage above and other sections in the Lazaridis reference teach that routing to an 
endpoint device may depend on the information transmitted (voice, word document, etc.). In 
contrast, claim 36 recites receiving "information to transmit to at least one of the user 
terminals and a user terminal identifier for identifying the at least one of the user terminals". 
Thus, the claim recites two things received by the transfer device, information to transmit 
jind a user terminal identifier (which is other than a network address of a user terminal). It is 
the user terminal identifier, not the information to transmit (as recited in the passage), that is 
used to identify a user terminal. Thus, claim 42, and claims which depend on claim 42, are 
patentable over the cited art.. 

Claim 50 

With regard to claim 50, the Office Action states that the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. Similar to the arguments discussed 
above with respect to claim 24, the Lazaridis reference does not teach programming code for 
"rejecting the push-type information if the information provider is not registered with the 
transfer device" recited in claim 50. Therefore, claim 50, and claims depending on claim 50, 
are patentable over the cited references. 
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Claim 55 

With regard to claim 55, the Office Aption stales thai the Lazaridis reference teaches 
each of the limitations. Applicants respectfully disagree. 

The Lazaridis reference docs not teach the information managing portion including 
"registering the user terminals with the information provider server \ As discussed above, 
the Lazaridis reference does not teach this "registering"' limitation. Therefore, claim 55, and 
claims depending on claim 55> are patentable over the cited references. 

Claim 59 

With regard to claim 59, the Office Action stales that the Lazaridis reference and U.S. 
Patent 6,260,027 (Takahashi et al.) renders the claim obvious. Applicants respectfully 
disagree. The Office Action states the Lazaridis reference teaches all of the limitations 
except for the use of management numbers and their one-io-one correspondence with 
telephone numbers of the user terminals. The Office Action cites the Takahashi reference as 
teaching the use of a management number. The Office Action further states that "a user 
management number in applicant's context is merely an application of a ubiquitous 
identification number system in use for millennia. 1 ' Applicants respectfully disagree- 
As discussed above, the Lazaridis reference fails to teach or suggest registering the 
user terminals with the information provider server. Moreover, the Takahashi reference does 
not teach the use of a user management number as currently claimed. Takahashi discloses a 
management number (No) which is generated by service providing terminal 3 and sent to 
user terminal 2. However, Takahashi does not teach a user management number as currently 
claimed. As an initial matter, Takahashi provides little teaching as to how the management 
numbers are generated or how they are used. Moreover, Takahashi does not teach the use of 
user management numbers in the context as claimed - an information provider server in an 
Internet sending information via a transfer device acting as a gateway to a plurality of user 
terminals in a mobile telephone network. Further, the user management numbers are used 
for a one-to-one correspondence for telephone numbers, not taught by the Takahashi 
reference. Finally, the Office Action's reliance on "the experience of millennia" is not a valid 
basis for rejection, particularly given the use of a user management number in the present 
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context. 

Claim 61 % 1 

With regard lo claim 6 ) , the Office Action slates that the Lazaridis reference teaches 
all of the limitations. As discussed above, the Lazaridis reference does not teach identifying 
means which identify lt a set of attributes with respect to users of the user terminals". The 
Office Action cites coh 7, line 53 to Col. 8 ? line 5 as support, reproduced below: 

Assuming that the redirector program 12 is activated, and has been configured 
by the user (either through the sensing of an internal, network or external event) to 
replicate certain user data items (including messages of type A or C) to the mobile 
device 24, when the message A is received at the host system 10, the redirector 
program 12 detects its presence and prepares the message for redirection to the 
mobile device 24. In preparing the message for redirection, the redirector program 12 
could compress the original message A, could compress the message header, or could 
encrypt the entire message A to create a secure Jink to the mobile device 24. 

Also programmed into the redirector 12 is the address of the user's mobile data 
communication device 24, the type of device, and whether the device 24 can accept 
certain types of attachments, such as word processing or voice attachments. If the 
user's type of mobile device cannot accept these types of attachments, then the 
redirector 12 can be programmed to route the attachments to a fax or voice number 
where the user is located using an attached fax or voice machine 30. 

As shown in the above excerpt and discussed uvmore detail above, the Lazaridis reference 

does not teach user attributes, but rather aspects of the attachment itself (such as word 

processing or voice attachments). This is entirely unrelated to the user of the user terminal. 

Moreover, contrary to the assertion in the Office Action, the sending of the attributes is not 

inherent in the Lazaridis reference. Therefore, claim 60 is patentable over the cited art. 

Claim 62 

With regard to claim 62, the Office Action states that the Lazaridis reference and U.S. 
Patent 6,260,027 (Takahashi et aL) renders the claim obvious. Applicants respectfully 
disagree. As discussed above with respect to claim 59, the use of the user management 
number in the present context (in combination with a mobile telephone network) and the one- 
to-one correspondence with telephone numbers is not taught or suggested by the cited 
references. Therefore, claim 62 is patentable over the cited art. 
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Claim 63 

With regard to claim 63, Ihe Office Action slates lhal ihe Lazaridis reference leaches 
all of The limitations. As discussed above with regard to claim 6), the Lazaridis reference 
does not leach requesting means for requesting attributes of a user of the user terminal and 
does not teach receiving information from an information provider server that designated 
attributes which match the registered attributes. Therefore, claim 63 is patentable over the 
cited art. 

SUMMARY 

Applicants submit that based on the foregoing remarks, the rejections have been 
traversed, and that the claims are in condition for allowance. Should there be any remaining 
formalities, the Examiner is invited to contact the undersigned attorneys for the Applicants 
via telephone if such communication would expedite this application. 

Respectfully submitted. 




Registration No. 40,767 
Attorney for Applicant 

BRINKS HOFER GILSON & LIONE 
P.O. BOX 10395 
CHICAGO, ILLINOIS 60610 
(312) 321-4200 
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